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Abstract.  This  paper  covers  the  different  types  of  teams  the  authors  have  en¬ 
countered  as  NAVAIR  Internal  Process  Coaches  and  how  they  approached  Process 
Improvement  with  them,  with  special  emphasis  on  the  curmudgeons  (bad-tempered, 
difficult,  or  cantankerous  persons). 

Introduction 

There  are  many  approaches  to  Continuous  Process  Improve¬ 
ment  (CPI).  The  authors  have  observed,  participated,  or  assisted 
in  numerous  CPI  initiatives  in  both  private  industry  and  United 
States  Federal  Government  service.  Those  efforts  included  Agile, 
Capability  Maturity  Model-Software  (CMM®-SW),  Capability 
Maturity  Model  Integration  (CM Ml®),  Total  Quality  Management 
(TQM),  High  Performance  Qrganization  Training  (HPQ),  Lean  Six 
Sigma,  Personal,  Software  Processes  (PSP^^),  Rational  Unified 
Process  (RUP),  the  Team  Software  Processes  (TSP^^),  and  pos¬ 
sibly  a  few  others  which  may  have  been  forgotten.  All  of  these 
systems  have  a  good  chance  for  success  if  the  people  and  orga¬ 
nizations  to  which  they  are  being  applied  are  properly  prepared, 
and  the  initiatives  are  managed  in  the  same  manner  as  a  project. 
A  good  example  of  this  would  be  the  use  of  the  ADKAR  model, 
with  its  five  objectives,  to  prepare  for  and  execute  a  process 
improvement  effort  [1  ]: 

•  Awareness  of  the  need  for  change 

•  Desire  to  support  and  participate  in  the  change 

•  Knowledge  of  how  to  change 

•  Ability  to  implement  desired  skills  and  behaviors 

•  Reinforcement  to  sustain  the  change 


Innovators 


Figure  1 :  An  adapted  “Innovation  Adoption  Curve” 
showing  the  Innovators,  the  Early  Adopters,  and  the 
“Never  Adopters.” 


Another  good  example  would  be  the  use  of  the  Software  Engi¬ 
neering  Institute  (SEI)  IDEAL  model,  IDEAL  has  five  steps,  the  last 
four  of  which  are  repeated  in  a  continuous  cycle  of  process  improve¬ 
ment  [2]:  Initiating,  Diagnosing,  Establishing,  Acting,  and  Learning. 

What  can  a  process  improvement  coach  do  though  when  the 
proper  preparations  aren’t  made  and  the  people  are  not  effective¬ 
ly  prepared  in  advance?  If  the  success  of  a  CPI  initiative  for  any 
given  team  is  defined  as  the  whole  team  undertaking  and  sustain¬ 
ing  CPI,  then  there  are  many  paths  to  the  adoption  of  CPI. 

When  preparing  to  introduce  CPI  in  this  sort  of  environment, 
it  is  important  to  remember  that  all  pre-CPI  teams  are  different. 
Some  are  made  up  of  process  champions,  while  others  seem  to 
have  only  arm-folded  curmudgeons.  Using  our  experiences  as 
NAVAIR  Internal  process  coaches  we  will  address  the  follow¬ 
ing  questions.  How  are  these  team  types  different?  How  can 
a  process  coach  take  these  teams  from  ad-hoc  processes  to 
disciplined  superstars?  Are  special  approaches  required?  Most 
importantly,  and  this  is  where  we  spent  most  of  our  time  as  pro¬ 
cess  coaches,  what  kind  of  techniques  can  you  use  to  deal  with 
the  more  difficult  teams? 

The  authors  believe  that  the  answers  they  have  found  are  ap¬ 
plicable  to  most  process  improvement  initiatives.  While  this  article 
focuses  on  recent  NAVAIR  initiatives  which  utilized  the  Team  Pro¬ 
cess  Integration  (TPI),  it  is  because  the  TPI  was  able  to  provide 
them  with  data  from  which  to  draw  conclusions  about  successful 
approaches  to  pursuing  CPI. 

The  TPI  is  a  NAVAIR  derivative  of  the  SEI’s  TSP  The  TSP  is  a 
disciplined  approach  to  writing  software  originally  based  upon  the 
SEI  Capability  Maturity  Model  -  Software  (CMM-SW).  The  TPI 
takes  the  process  scripts  of  the  TSP  and  strips  out  the  elements 
that  are  specific  to  software  development.  This  leaves  a  general¬ 
ized  set  of  process  scripts  which  may  be  customized  and  applied 
to  support  the  planning,  project  execution,  reporting,  and  process 
improvement  efforts  of  both  software  and  non-software  teams. 

To  begin  the  discussion  of  the  different  types  of  teams  let  us 
briefly  review  the  by-the-book  approach  to  instituting  the  TSP 
familiar  to  its  practitioners.  We  start  with  the  “Innovators”  and 
“Early  Adopters”  as  defined  in  the  “Innovation  Adoption  Curve” 
(Figure  1 )  [3].  They  are  willing  to  try  new  things,  they  work  hard 
toward  success,  and  they  socialize  that  success  to  their  friends. 
Their  friends  are  encouraged  to  try  the  new  techniques  and  the 
good  new  spreads  from  there.  It  has  been  the  authors’  personal 
experience  in  both  the  private  software  industry  and  the  DoD 
that  this  is  seldom  the  approach  used.  It  has  been  more  typical  in 
these  working  environments  for  management  to  simply  man¬ 
date  all  teams  to  use  a  new  process  improvement  framework. 
While  some  teams  may  respond  well  to  that  approach,  many  do 
not.  Whether  they  do  or  not  often  depends  on  the  percentage 
of  individual  ‘laggards’  on  a  given  team.  If  the  team  is  made  up 
almost  exclusively  of  laggards,  we  call  them  “Never  Adopters”  and 
a  special  approach  will  be  required. 

Different  Working  Environments 

The  by-the-book  approach,  as  described  above,  was  devel¬ 
oped  by  experts  who  hoped  that  organizations  seeking  process 
improvement  would  pursue  it  in  an  idealized,  formal  fashion.  Some 
of  the  characteristics  of  that  idealized  approach  are: 

•  the  project  is  new 

•  the  members  of  the  project  might  never  have  worked 
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together  before 

•  everyone,  from  management  to  the  individual  engineer, 
is  properly  trained  and  prepared 

•  the  purpose  of  the  weeklong  Team  Project  Planning 
Session  (aka  “the  Launch”)  is  to  build  the  team 

•  the  organization  has  sufficient  communication  between 
projects  to  allow  the  “Adoption  Curve  Strategy”  to  work 
across  the  organization 

This  strategy  has  been  used  on  numerous  teams  in  the  non- 
Academic  environments  of  both  the  DoD  and  private  industry. 
During  the  course  of  those  efforts  some  differences  between  the 
Academic  and  non-Academic  environments  were  identified.  In 
general,  in  the  non-Academic  environments: 

•  the  project  is  to  enhance  and  maintain  an  existing  product 

•  the  team  already  exists  and  team  members  have  often  been 
working  together  for  years 

•  in  the  interest  of  schedule,  importance,  and  budget,  not 
everyone  is  trained  properly,  if  at  all 

•  the  Launch  is  used  to  introduce  “Best  Practices” 

•  few  of  the  projects  in  a  large  organization  talk  to  each  other, 
making  the  dissemination  of  TSP/TPI  a  grindingly  slow 
process 

These  differences  in  environment  are  important.  Depending  on 
the  type  of  team,  they  can  make  a  by-the-book  approach  unwork¬ 
able. 

Different  Types  of  Teams 

It  is  said  that  the  first  step  to  recovery  is  admitting  you  have  a 
problem.  Based  on  that,  we  have  found  that  teams  may  be  divided 
into  two  general  categories,  depending  on  who  is  doing  the  “ad¬ 
mitting.”  Is  it  the  team  or  their  management? 

Self-Selected  Teams 

These  are  the  teams  who  know  that  something  is  wrong  with 
the  way  the  work  is  being  done  and  they  are  personally  motivated 
to  do  something  about  it.  In  our  experience,  these  teams  will 
usually  identify  one  of  three  primary  reasons  to  adopt  process 
improvement: 

1.  To  fix  broken  management:  Irrational  management  has  cre¬ 
ated  a  chaotic  environment 

2.  To  obtain  a  process  the  team  will  use:  The  Team  Lead  has 
worked  on  teams  with  good  processes  and  wants  their  new  team 
to  start  out  on  the  right  foot 

3.  To  save  the  broken  schedule:  The  product  is  chronically  late 
and  the  team  as  a  whole  decides  that  they  need  a  way  to  judge 
their  progress. 

Management-Selected  Teams 

If  it  is  the  management  that  decided  there  is  a  problem,  which 
they  think  may  be  solved  by  process  improvement;  it  is  usually  for 
one  of  the  following  reasons: 

1 .  To  fix  the  broken  team:  They  have  teams  where  the  product 
is  never  delivered  or,  if  it  is,  the  product  doesn’t  work 

2.  To  introduce  best  practices:  Management  read  about  a  pro¬ 
cess  improvement  framework  in  a  White  Paper 

3.  To  gain  insight  into  the  schedule:  Their  teams  are  unpredict¬ 
able  and  product  delivery  is  never  known  until  the  last  minute 

It  has  been  our  experience  that  Management- Selected  teams 
are  typically  neither  convinced  to,  nor  properly  prepared  to  un¬ 


dertake  process  improvement.  They  are  instructed  to  do  it.  Some 
teams  will  take  this  new  effort  on  willingly,  but  the  Never  Adopters 
will  not.  The  probability  that  these  types  of  teams  will  be  success¬ 
ful  in  the  pursuit  of  mandated  Continuous  Process  Improvement 
can  vary  widely. 

Introduction  Strategies  for  Self  Selected  Teams 

Self-Selected  teams,  by  their  nature,  are  generally  not  difficult 
to  deal  with  and  can  be  expected  to  attempt  to  take  on  all  the 
TSP  or  TPI  practices  from  the  start.  A  coach  should  not  have  to 
spend  much  time  with  them  outside  of  what  might  normally  be 
expected.  These  are  the  teams  where  the  Innovation  Adoption 
Curve  works,  and  for  which  TSP  coaches  are  trained. 

In  general,  the  team’s  chance  of  success  is  good,  but  not 
always. 

Self-Selected:  Fix  the  broken  Management 

Occasionally,  an  engineer  from  a  disciplined  team  joins  a 
new  team  and  the  new  surroundings  are  not  that  for  which  they 
bargained.  The  engineer  figures  out  too  late  that  the  new  environ¬ 
ment  is  not  quite  as  disciplined  as  they  had  imagined,  but  at  least 
they  figure  that  they  can  control  their  own  world. 

There  is  a  low  chance  of  success  here  because  it  is  likely  that, 
intentionally  or  unintentionally,  management  itself  is  fostering 
an  environment  of  chaos  and  will  oppose  attempts  to  introduce 
discipline. 

Is  there  a  good  reason  for  a  person  to  pursue  process  improve¬ 
ment  in  this  environment  even  though  the  chance  of  success  is 
low?  Yes.  That  person  builds  a  record  of  their  attempt  at  discipline 
and  that  will  serve  them  well  later  on  when  the  project  fails  and 
management  is  attempting  to  assign  blame.  One  of  the  authors  of 
this  article  assisted  an  engineer  in  this  situation,  and  because  that 
engineer  had  planned,  documented,  and  tracked  their  work,  they 
were  recognized  by  upper  management  as  a  competent,  honest, 
and  diligent  employee:  complaints  lodged  against  him  by  his  ir¬ 
rational  manager  notwithstanding. 

Self-Selected:  Obtain  a  Process  the  Team  Will  Use 

In  this  instance  the  team  lead  is  an  innovator,  an  early-adopter 
type,  or  a  person  who  may  have  formerly  worked  on  a  high- 
discipline  team.  They  understand  that  chaos  is  a  poor  product 
development  strategy.  They  want  a  team  process  and  are  willing 
to  try  new  things.  As  the  new  team  lead  they  have  an  opportunity 
during  their  new  Team  Lead  “honeymoon”  period  to  introduce  CPI 
and  they  make  the  most  of  it. 

The  overall  chance  of  success  in  adopting  Process  Improve¬ 
ment  is  high. 

Self-Selected:  Save  the  Broken  Schedule 

In  this  instance,  an  entire  team  comes  to  a  consensus  that 
something  is  wrong,  be  it  schedule,  cost,  or  quality.  Not  only  do 
they  admit  they  have  a  problem,  they  are  willing  to  accept  change 
in  order  to  find  a  better  way  to  do  business. 

The  overall  chance  of  success  in  adopting  Process  Improve¬ 
ment  is  high. 

The  Management-Selected  Teams 

Teams  are  usually  selected  for  Process  Improvement  when 
management: 
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•  Understands  there  is  a  problem  with  a  team’s  performance 

•  Hears  about  other  teams’  success  with  process 
improvement 

•  Wants  a  process  coach  to  fix  their  broken  team 

Management- Selected  teams  all  respond  to  the  new  CPI  initia¬ 
tive  in  pretty  much  the  same  way  and  are  the  process  coach’s 
biggest  hurdle.  They  are  often  staffed  with  experienced  profes¬ 
sionals  who  have  seen  many  Process  Improvement  flavor-of-the- 
month  initiatives  start  and  fail,  or  worse,  start  and  be  abandoned 
with  the  next  change  in  management.  If  a  process  coach  tries 
using  the  by-the-book  approach  with  these  teams,  the  probability 
of  success  is  low.  This  is  because  the  Canon  of  this  approach 
often  runs  squarely  into  the  Reality  of  the  work  environments  of 
the  DoD  and  Industry  (Table  1).  It  is  because  these  teams  can  be 
such  a  challenge  for  a  process  coach  that  the  remainder  of  this 
article  will  focus  on  them. 

It  is  likely  for  the  Management- Selected  teams  that  at  least 
one  member  of  the  team  with  significant  professional  experience 
will  be  cynical  and  has  learned  that  the  best  strategy  for  avoiding 
“work  disruption”  is  to  passive-aggressively  resist  the  latest  initia¬ 
tive.  If  all  the  members  of  the  team  fit  that  description  then  the 
process  coach  has  entered  the  “Never- Adopters”  portion  of  the 
Innovation  Adoption  curve.  A  coach  will  spend  much  more  time 
with  these  teams  than  with  a  self-selected  team,  and  the  bulk  of 
that  time  will  be  a  seemingly  endless  effort  to  cajole  the  team  into 
complying  with  the  initiative. 

For  the  Never  Adopters,  the  introduction  of  process  improve¬ 
ment  must  be  done  slowly  and  incrementally.  Overwhelming  them 
with  process  will  just  give  them  the  ammunition  they  need  in 
their  complaints  to  management  that  what  the  process  coach  is 
asking  cannot  be  accomplished  and  still  expect  them  to  get  work 
done.  Worse,  the  ferocity  of  their  passive-aggressive  resistance 
will  blind  them  to  any  value  there  is  from  the  process  improve¬ 
ment  initiative.  At  best,  they  will  do  the  very  minimum  they  can  get 
away  with  and  still  be  seen  to  be  complying.  In  some  cases  they 
may  even  outright  refuse  to  participate.  Then,  after  the  initiative 
collapses  due  to  the  team’s  intentional  failure  to  perform,  they  will 
point  to  the  lack  of  progress  and  data  and  say  that  the  process 
is  a  hoax.  They  will  say  this  even  in  the  face  of  evidence  of  other 
team’s  successes  with  the  same  initiative.  Typically  their  explana¬ 
tion  is  that  their  work  is  unique  and  not  at  all  like  the  other  team, 
whose  success  is  either  some  sort  of  very-specific  lucky  break,  or 
an  outright  lie. 

In  a  further  effort  to  justify  their  failure,  they  will  spread  this 
word  throughout  the  larger  organization  and  that  will  “poison  the 


well.”  As  a  result,  the  organization  will  be  less  likely  to  try  that 
brand  of  process  improvement  in  the  future  and  the  coaching 
organization  will  lose  other  process  improvement  opportunities. 

If  management  keeps  up  the  pressure  for  process  improve¬ 
ment,  despite  the  manufactured  failure  and  team  complaints, 
then  there  is  a  risk  of  the  organization  losing  valuable  corporate 
knowledge  through  early  retirements  and  lateral  transfers. 

So,  if  taking  the  by-the-book  approach  is  likely  to  produce  poor 
results,  will  rolling  out  process  improvement  in  small  doses  really 
result  in  long-term  success?  If  the  goal  is  to  change  the  culture 
and  improve  the  practices  of  an  organization,  then  the  experi¬ 
ences  of  the  NAVAIR  Process  Coaches  suggest  that  the  answer 
is  ‘Yes’ 

Introduction  Strategies  for  the  “Never  Adopters” 

Everyone  knows,  from  the  manager  who  orders  it,  the  process 
coach  who  has  to  introduce  it,  and  the  team  who  has  to  imple¬ 
ment  it,  that  they  are  eventually  going  to  have  to  eat  the  entire 
process-improvement  elephant.  So,  how  do  you  get  the  “Never- 
Adopters”  to  undertake  the  effort?  The  key  is  to  convince  the 
team  to  agree  to  try  a  bite  of  the  trunk,  just  to  see  what  it  tastes 
like. 

Ask  the  team  to: 

•  plan  their  work:  introduce  the  team  to  projects  with 
detailed  plans 

•  track  their  work:  start  to  instill  process  discipline 

•  think  about  Quality:  get  them  to  consider  the  possibility  of 
building  on  the  process 

From  this  modest  introduction,  the  process  coach  wants  the 
team  to  come  to  understand  that  collecting  performance  data  is 
neither  difficult  nor  time  consuming,  that  their  performance  data 
will  not  be  used  against  them,  and  that  there  is  value  for  them 
personally  in  the  data  which  they  are  collecting. 

Introduce  Planning 

Of  all  the  process  improvement  practices  this  brings  the 
greatest  benefit,  but  it  is  not  a  common  practice:  have  the  team 
who  will  be  creating  the  product  build  the  project  development 
plan.  Many  engineers  in  industry  and  the  DoD  have  never  seen  a 
detailed  plan,  let  alone  participated  in  making  one.  The  planning 
effort  might  not  be  considered  much  fun  at  first,  but  the  resulting 
plan  will  be  popular.  Here  are  two  quotes  from  the  end  of  one 
such  planning  session: 

“This  is  the  first  time  I’ve  known  what  I  should  be  doing  on  this 
project.” 


Canon  vs.  Reality 

Canon 

Reality 

Each  project  starts  with  a  new  team  of  people  who  have  never 
before  worked  together. 

The  team  is  already  established,  sometimes  for  more  than  a 
decade. 

The  arduous  effort  of  a  detailed  weeklong  planning  session  will 
'jell'  a  collection  of  strangers  into  a  high-performance  team. 

The  team  is  already  jelled,  and  if  they  aren't,  they  soon  will  be  as 
the  process  coach  becomes  their  common  enemy. 

You  roll  out  the  entire  process  at  once.  The  team  is  exposed  to 
everything  and  is  expected  to  put  all  of  it  into  practice, 
improving  steadily  over  time. 

You  can  only  get  the  'difficult'  teams  to  accept  some  small 
portion  of  the  overall  process. 
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“We  should  always  have  a  plan.” 

Start  the  project  team  off  with  basic  planning  techniques.  Have 
the  team  create  a  task  list,  estimate  task  size  in  terms  of  time  and 
keep  the  workflows,  if  there  are  any,  simple. 

Introduce  Tracking 

Now  the  team  has  a  plan,  how  are  they  going  to  track  prog¬ 
ress?  Have  them  use  a  project  tracking  tool.  There  are  a  number 
of  commercial  programs  available,  and  several  of  them  are  free 
to  use.  By  using  one  of  these  tools,  each  member  of  the  team 
will  record  their  personal  time  against  their  tasks,  and  mark  those 
tasks  as  completed  when  they  are  finished  with  them.  Emphasize 
to  the  team  that  tracking  their  own  work  will,  with  very  little  effort 
on  their  part,  provide  them  with  personal  insight  into  the  following 
areas:  Time  on  task.  Earned  value.  Schedule  progress.  Forecasts, 
and  Accuracy  of  estimates. 

Introduce  Quality 

Will  a  team  have  good  quality  assurance  practices  right  from 
the  start?  That  is  unlikely.  Will  they  have  a  quality  product?  That 
depends.  Their  quality  will  probably  be  better  than  in  the  era 
before  they  started  to  make  detailed  plans,  if  only  because  their 
software  interfaces  are  usually  better  defined.  The  key  is  that  the 
process  coach  starts  the  discussion  on  quality  which  primes  the 
team  for  introducing  more  disciplined  quality  practices  later  on. 

Build  on  the  Process 

Will  the  team  have  high-quality  personal  data  at  the  end  of  the 
first  project  cycle?  Probably  not.  Most  likely  they  weren’t  too  dili¬ 
gent  in  recording  their  own  data,  but  it  is  still  data.  After  the  first 
cycle,  the  team  members  will  begin  to  see  that  their  plans  have 
useful  information  in  them,  and  they  will  see  that  the  data  wasn’t 
as  good  as  it  could  have  been.  Most  engineers  like  data  and  the 
desire  for  better  data  encourages  them  to  improve  the  way  in 
which  they  have  been  tracking  their  effort.  It  also  leads  them  to 
begin  wondering  “if  this  data  is  useful,  what  else  might  I  track  that 
would  be  of  interest?”  They  begin  to  think  “if  some  process  isn’t 
bad,  more  process  might  be  better.”  It  is  in  this  way  that  individual 
members  take  themselves  from  ‘Process  Resistors’  to  ‘Process 
Defenders’  and  then  on  to  ‘Process  Advocates.’  Once  that  starts, 
the  team  is  on  the  road  to  higher  performance. 

Team  Results  Over  Time 

So,  the  strategy  outlined  for  introducing  CPI  to  Never- Adopters 
is  to  start  them  out  with  simple  processes  and  build  on  them 


—  Plan  —  Actual 


over  time.  It  will  certainly  take  longer,  but  will  it  actually  produce 
positive  results?  The  answer  is  yes,  as  the  results  of  the  efforts 
of  two  different  types  of  TPI  teams  will  show:  a  team  of  software 
testers,  and  an  Interdisciplinary  team  of  Software,  Electronic,  and 
Mechanical  engineers. 

Team  A:  The  Software  Test  Team 

Figure  2  shows  how  a  team  of  software  product  testers  fared 
over  time  in  their  tracking  of  the  actual  hours  associated  with  their 
Task  Time.  The  first  chart  shows  the  data  for  the  first  TPI  cycle, 
and  the  second  for  the  fourth  TPI  cycle:  a  span  of  two  years.  The 
red  lines  represent  the  planned  accumulation  of  task  hours  as  es¬ 
timated  during  the  launches.  The  blue  lines  are  the  actual  number 
of  task  hours  as  logged  by  the  team  during  the  project  cycles. 

If  you  move  the  Actual  line  of  the  fourth  project  cycle  to  the  left 
to  account  for  the  delay  in  the  start  of  testing,  you  can  see  that  the 
team  is  accurately  estimating  their  availability  to  work  on  the  effort. 

Figure  3  shows  how  the  team  fared  in  tracking  their  earned 
value  (EV)  over  the  span  of  the  same  four  project  cycles.  The  red 
lines  represent  what  was  planned  at  the  launches.  The  blue  lines 
are  the  EV  that  the  team  accrued  during  the  project  cycles.  The 
green  lines  are  the  actual  cost  of  that  EV  in  terms  of  hours. 

While  the  actual  EV  never  matches  the  EV  progress  as  antici¬ 
pated  by  the  planning  tool,  the  actual  EV  and  the  actual  cost  of 
that  EV  are  very  close.  As  a  result  of  using  the  TPI,  this  team  is 
able  to  accurately  estimate  the  size  of  their  tasks,  even  though 
they  were  estimating  solely  on  the  basis  of  time. 

Team  B:  The  Interdisciplinary  Team 

How  well  did  this  approach  work  for  the  interdisciplinary  TPI 
Team  composed  of  software,  electronic,  and  mechanical  engi¬ 
neers?  The  results  can  sometimes  be  startling.  Figure  4  shows 
the  team’s  performance  during  their  first  TPI  cycle.  The  red  line 
represents  the  planned  accumulation  of  task  hours  as  estimated 
during  the  launch.  The  blue  line  is  the  number  of  task-hours  as 
logged  by  the  team. 

It  is  all  the  more  impressive  as  they  had  only  one  day  of  TPI 
training. 

The  outcome  is  equally  exciting  for  their  EV  tracking  (Figure  5), 
where  the  tasks  were,  for  the  most  part,  simple  tasks  estimated  in 
units  of  hours  or  days,  not  Source  Lines  of  Code  (SLOC)  or  some 
other  more  direct  measurement.  The  red  line  represents  what 
was  planned  at  the  launch.  The  blue  line  is  the  EV  that  the  team 
accrued  over  time.  The  green  line  is  the  actual  cost  of  that  EV  in 
hours. 


Figure  2:  Direct  Time  charts  for  a  team  of  software  testers:  the  first  cycle  on  the  left  and  the  fourth  on  the  right 
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Figure  3:  Earned  Value  charts  for  a  team  of  software  testers:  the  first  cycle  on  the  left  and  the  fourth  on  the  right. 


Figure  4:  Direct  Time  chart  for  an  Interdisciplinary  Figure  5:  Earned  Value  chart  for  an  Interdisciplinary  team  of 

team  of  engineers  from  their  first  project  cycle.  engineers  from  their  first  project  cycle. 


First  Cycle  Comments 

Second  and  Third  Cycle  Comments 

Fourth  Cycle  Comments 

Launch  was  dreaded  by  everyone 

More  comfortable  with  the  process  and 
the  plan  let  me  know  what  to  work  on 
next 

Liked  having  historical  data.  Made  the 

Post  Mortem  less  painful  than  in  the  past 

"What  have  we  done  to  ourselves?!" 

Liked  consulting,  designing,  and  planning 
together 

Work  patterns  are  emerging 

The  Launch  is  one  more  thing  taking  time 
out  of  my  availability  for  work 

Injected  discipline  into  work.  Helped  to 
keep  focus 

Need  more  rigorous  planning 
requirements 

Not  nearly  as  bad  an  experience  as  1 
thought  it  would  be.  Turned  out  to  be 
relatively  painless 

Interesting  to  see  the  kind  of  statistics 
being  collected 

Stopped  launch  tasks  to  work  out  issues 
and  sync  team  understanding 

The  Project  Launch  was  efficient  and 
effective 

Emphasized  the  importance  of  logging 
time  as  you  go,  instead  of  back  filling 

The  team  lead  and  planning  manager  are 
spending  less  time  on  preparing  the 
monthly  management  report  as  the 
necessary  information  is  readily  available 

The  Coach  accepted  that  it  was  more 
important  to  start  measuring  the  existing 
process  rather  than  force  the  team  to 
adopt  practices  that  the  team  will 
probably  not  do 

Kept  the  Coach  employed 

Next  time  we  should  have  more  detail  on 
the  number  and  type  of  Development 
Tasks 
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Table  2:  Typical  comments  from  the  first  project  cycle.  Color  added  for  emphasis. 
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What  About  Quality? 

It  has  it  been  our  experience  that  convincing  the  never-adopter 
teams  to  perform  quality  assurance  practices,  other  than  the 
usual  test-and-fix,  has  been  one  of  the  most  difficult  areas  of  our 
CPI  efforts.  At  the  time  that  this  article  was  written,  some  of  our 
teams  had  on  their  own  initiative  taken  on  peer  reviews,  and  they 
do  seem  to  be  more  open  to  additional  quality  control  practices, 
but  they  are  just  getting  started  on  this  part  of  their  journey.  It  is 
too  early  yet  to  know  what  sort  of  progress  to  expect. 

Changes  in  Attitude 

It  was  hinted  at  earlier  in  this  article  that  if  a  process  coach 
took  the  incremental  CPI  path,  the  team  members’  attitudes 
towards  process  improvement  would  become  more  positive  over 
time.  The  evidence  for  that  change  in  attitude  may  be  found  in  a 
comparison  of  selected  comments  collected  from  the  launches 
and  postmortems  of  four  six-month  project  cycles  of  four  TPI 
teams  (Table  2). 

The  teams  went  into  their  first  project  cycle  launch  with  the 
idea  that  it  would  be  a  useless,  miserable  experience.  They  left 
feeling  that: 

•  it  wasn’t  unbearable 

•  they  had  some  control  over  their  work 

•  the  plan  generated  during  the  launch  was  their  plan 

•  they  would  like  to  have  had  more  detail  in  the  plan 

By  the  Second  and  Third  project  cycles  the  launches  are  taking 
less  time,  and  now  that  they  know  what  to  expect,  are  beginning 
to  seem  easy.  More  importantly,  to  the  process  coach  anyway;  the 
coach  has  gone  from  being  seen  as  the  common  enemy  to  being 
part  of  the  work  environment.  In  essence  they: 

•  worked  together  as  a  team  and  enjoyed  it 

•  found  the  rigor  of  the  new  processes  to  be  beneficial 

•  liked  that  there  was  data  to  analyze 

•  wanted  better  data  from  the  next  cycle 

The  Fourth  cycle  comments  suggest  that  after  two  years  of 
following  the  incremental  CPI  path,  the  project  launches  are  now 
easy,  safe,  and  relatively  fun.  The  teams: 

•  have  historical  data  they  can  use  to  estimate  their  future 
work 

•  are  beginning  to  take  control  of  their  current  work 

•  are  working  together  to  create  the  plan  and  iron  out  the 
unclear  parts 

•  understand  that  process  improvement  is  saving  them  time- 
and -effort 

These  results  are  evidence  of  a  strong  improvement  in  team’s 
attitudes  towards  CPI. 

Final  Comments 

The  long-term  goals  of  Process  Improvement  should  be  to 
introduce  and  sustain  a  culture  of  continuous  process  improve¬ 
ment.  The  results  of  the  incremental  approach  used  by  the 
authors  suggest  that  not  all  teams  have  to  take  the  steep  path 
towards  that  goal.  After  several  years  of  coaching  Never- Adopter 
teams,  NAVAIR  Process  Coaches  have  seen  steady  improvement 
in  the  ability  of  their  TPI  teams  to  estimate  their  level  of  effort 
and  schedule,  and  have  seen  positive  changes  in  team  member’s 
attitudes  towards  process  improvement.  While  the  journey  for 
these  teams  is  not  yet  over,  it  appears  that  by  taking  the  slow. 


incremental  path,  reluctant  teams  may  be  able  to  make  themselves 
into  process-improvement-oriented  teams  which  actively  search  for 
ways  to  do  business  better. 

Disclaimer; 

CM  Ml,®  CMM,®  PSR^^and  TSP^^are  registered  in  the  U.S.  Patent 
and  Trademark  Office  by  Carnegie  Mellon  University. 
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